home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 8478 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  6.5 KB
  1. Path: goanna.cs.rmit.EDU.AU!not-for-mail
  2. From: ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe)
  3. Newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2
  4. Subject: Re: Hungarian notation - whoops!
  5. Date: 19 Feb 1996 16:34:29 +1100
  6. Organization: Comp Sci, RMIT, Melbourne, Australia
  7. Message-ID: <4g9255$74s@goanna.cs.rmit.EDU.AU>
  8. References: <30C40F77.53B5@swsbbs.com> <4fc157$jsf@goanna.cs.rmit.EDU.AU> <dewar.823793746@schonberg> <4fms62$c0p@goanna.cs.rmit.EDU.AU> <4ft1ruINN6dr@keats.ugrad.cs.ubc.ca>
  9. NNTP-Posting-Host: goanna.cs.rmit.edu.au
  10. X-Newsreader: NN version 6.5.0 #0 (NOV)
  11.  
  12. I wrote:
  13.     The underlying base is not something I usually have to think about.
  14.     Most of my C code would work just as well in base 2, 3, 10, or even
  15.     balanced ternary.
  16.  
  17. c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes:
  18.  
  19. >But that is irrelevant since the standard restricts C to binary architectures.
  20.  
  21. Irrelevant to what?  I *know* what the C standard requires.  I keep a copy
  22. of the C standard (and the draft C++ standard, and Pascal, and Pascal
  23. Extended, and Ada 83, and Ada 95) close by my desk for handy reference.
  24. (The Fortran standards I have read on microfiche in the library.)
  25.  
  26. Of necessity, my Fortran and Pascal code cannot depend on the machine base.
  27. The fact that most of my C code turns out not to depend on the machine
  28. base even though it _could_ is most certainly relevant to a discussion of
  29. arithmetic in programming languages.  The form of my argument was "how
  30. much more".
  31.  
  32. It so happens that the C standard was carefully crafted to allow
  33. 2s complement, 1s complement, AND sign-and-magnitude.
  34.  
  35. I wrote:
  36.     But the fact that abs(x) may deliver a negative
  37.     number is something I have to live with the whole time.
  38.  
  39. Kazimir Kyheku again completely misses the point by a country mile.
  40.  
  41. >Not true. If you use the unsigned type, there is no such thing as overflow.
  42. >It's called residue math. No operation between two unsigned numbers yields
  43. >undefined results. The "X % Y" operation between unsigned numbers gives you the
  44. >smallest positive residue of X with respect to Y. Nothing undefined or
  45. >overflown about that. 
  46.  
  47. Kazimir, you will get a LOT further in life if you realise that people who
  48. disagree with you sometimes know what they are talking about.
  49.  
  50. The abs function in C is defined by the standard to take SIGNED int as
  51. parameter and deliver SIGNED int as result.  I am not claiming now, did
  52. not claim in the quoted message, and have never claimed in the past that
  53. C has no arithmetic types which cannot overflow.  (Actually, in UNIX
  54. Version 6, C _didn't_ have unsigned arithmetic; one did arithmetic on
  55. pointers to get unsigned.  I kid you not.)  By the way, "X % 0" is still
  56. undefined in unsigned arithmetic, so the claim that there is "nothing
  57. undefined" about it is not true.
  58.  
  59. Let me say it again:
  60.  
  61.     C, like many programming languages, has two mathematically
  62.     simple functions on ***SIGNED*** integers:
  63.         -x
  64.         abs(x)
  65.     An implementation of C, or any other such language, using
  66.     ones-complement or sign-and-magnitude arithmetic, easily
  67.     delivers correct outputs for all legal inputs to these operations.
  68.  
  69.     An implementation of C, or any other such language, using
  70.     twos-complement arithmetic, EITHER delivers incorrect outputs
  71.     for some legal inputs OR requires checking which is in practice
  72.     seldom offered.
  73.  
  74. Now, it so happens that a C compiler _is_ free to generate overflow checks
  75. for signed integer arithmetic, so a twos-complement implementation COULD
  76. guarantee "correct result or exception in all cases".  This is occasionally
  77. done for Pascal compilers.  I have access to three C compilers (lcc, gcc,
  78. and SPARCompiler cc) and if any of them has an option to check that signed
  79. arithmetic is done correctly I would be most grateful to be told what it is.
  80.  
  81. The practical consequence of this is that responsibility for ensuring that
  82. the input to unary minus or absolute value is in range is passed onto the
  83. programmer.  It is that which I am complaining about.  It doesn't make my
  84. life as a programmer one teeny tiny bit easier.
  85.  
  86. >The unsigned type is the ticket for portable integer modulo arithmetic.
  87.  
  88. Modular arithmetic in Ada 95 *is* the ticket for portable hackery.
  89. Unsigned arithmetic in C is indeed defined to be modulo 2**n for some
  90. n, but the bounds on n are very very loose, and the price of portability
  91. is much programmer-inserted masking.
  92.  
  93. More importantly, while overflow in signed arithmetic is a run-time error,
  94. unsigned arithmetic is very often a design-time error.
  95.  
  96. For example, suppose I want to count the number of times some event occurs.
  97. Unless I can *prove* at design time that the event can occur no more than
  98. 65535 times, use of 'unsigned int' in C is a design-time error.  There is
  99. at least one "commodity ISA" with a 300Mhz implementation getting close.
  100. How long is a 32-bit unsigned counter usable with 3e8 events per second?
  101.  
  102. A little over 14 seconds.
  103.  
  104. Overflows aren't the problem.  Restricted machine arithmetic is the problem.
  105.  
  106. >You need unaligned access if you want to have packed character arrays.
  107.  
  108. Sorry, but this simply isn't true.  It may surprise you to know that Pascal
  109. (the programming language which introduced the term 'packed') was first
  110. implemented on a machine which did not have unaligned access.  The
  111. machine in question had 60-bit words, 6 bit characters, and no character
  112. addressing, only word addressing (which made unaligned access impossible
  113. to express).
  114.  
  115. >If you
  116. >don't allow any sort of unaligned access, allowing only contiguous 32-bit words
  117. >to be accessed individually, you force size N arrays of characters to be 4N
  118. >bytes long. That is seen by some people as a waste of memory. 
  119.  
  120. You are confusing *unaligned* access with *byte* access.  Like it or not, it
  121. is a fact that the machines I was talking about DID support byte access,
  122. DID support packed arrays of character, but did NOT support unaligned
  123. access.
  124.  
  125. (Kazimir Kylheku) then contradicts himself and writes
  126.  
  127. >Just because a machine does enforce alignment doesn't mean that C cannot
  128. >operate on packed byte arrays.
  129.  
  130. >Chances are that you may even be working on an architecture whose compiler does
  131. >this, and not even know it! :)
  132.  
  133. I am working on a SPARC.  I also keep the SPARC V8 ABI manual close to my
  134. desk, and know it pretty well.  Architectures don't have unique compilers.
  135. I use three compilers.  I've only read one of them (lcc), but I occasionally
  136. check the output of the others (gcc, cc).  There are several other compilers
  137. for this architecture, including one which doesn't use register windows.
  138.  
  139. -- 
  140. Election time; but how to get Labour _out_ without letting Liberal _in_?
  141. Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
  142.